Skip to content
This repository has been archived by the owner on May 17, 2021. It is now read-only.

[AlarmDecoder] Added support for AlarmDecoder LRR Protocol #5019

Merged
merged 3 commits into from Jan 22, 2017

Conversation

LuckyMallari
Copy link
Contributor

Overview of LRR Support : http://www.alarmdecoder.com/wiki/index.php/LRR_Support
Alarm Decoder LRR Protocol : http://www.alarmdecoder.com/wiki/index.php/Protocol#LRR

Sample usage:

Item MUST be in this format:
String sAlarmLRR "LLR Msg: [%s]" (gAlarmPanel) {alarmdecoder="LRR:00#text"}

ITEMS:

String sAlarmLRR "LLR Msg: [%s]" (gAlarmPanel) {alarmdecoder="LRR:00#text"}
String sAlarmLRR_lastUser "Last User: [%s]" (gAlarmPanel)
String sAlarmLRR_lastEvent "Last Event: [%s]" (gAlarmPanel)
DateTime sAlarmLRR_lastEventDateTime ""  (gAlarmPanel)
String sAlarmLRR_lastPartition "Last Partition: [%s]" (gAlarmPanel)

RULES:


import java.util.Map;
import java.util.HashMap;
import com.google.common.collect.ImmutableMap

val Map<String, String> UserList = ImmutableMap.<String, String>builder()
    .put("001", "Installer")
    .put("002", "Master")
    .put("003", "User1")
    .put("004", "User2")
    .build()

rule "LRR Parser"
when
	Item sAlarmLRR received update
then
	var String msg = sAlarmLRR.state.toString();
	var String[] parts = msg.split(",");
	if (parts.length != 3) {
		logError("rules", "sAlarmLRR rule parsing error.");
	} else {
		logInfo("rules", "Parsing sAlarmLRR==> " + msg);
		var String user = UserList.get(parts.get(0));	
		var String partition = parts.get(1);
		var String event = transform("MAP", "alarm_LRR_eventmap.map", parts.get(2).toString);
		
		postUpdate(sAlarmLRR_lastUser, user);
		postUpdate(sAlarmLRR_lastPartition, partition);
		postUpdate(sAlarmLRR_lastEvent, event);
		postUpdate(sAlarmLRR_lastEventDateTime, new DateTimeType());
	}
end

@LuckyMallari LuckyMallari changed the title Added support for AlarmDecoder LRR Protocol [AlarmDecoder] Added support for AlarmDecoder LRR Protocol Jan 20, 2017
@watou
Copy link
Contributor

watou commented Jan 21, 2017

Thanks @LuckyMallari! @berndpfrommer OK to merge or do you have changes to suggest?

@LuckyMallari
Copy link
Contributor Author

@watou There are no breaking changes, so should be OK to just merge

Copy link
Contributor

@berndpfrommer berndpfrommer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • why is NUMTYPES initialized to 7? Shouldn't it be 6? Looks like a bug to me.
  • there are also changes to a different binding "diyonxbee?" included in the commit. These should not be commingled with this commit. The commit should only refer to the alarmdecoder binding.
  • there are a number of cosmetic changes (maybe it is space vs tabs, I can't see the difference). These changes should not be committed, as they obscure the true changes. If reformatting the code is necessary, that should be done in a separate commit that has no functional changes, only reformatting.

Copy link
Contributor

@watou watou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @berndpfrommer for your review! I agree with your first point. The minor reformats are a good side-effect of the formatter in the Eclipse IDE, so I think they are OK. And I don't see any changes to diyonxbee, so maybe that was removed with the second commit. In any case, @LuckyMallari, please adress the comment below and I believe it will be ready for merge, and thanks to both of you.

NUMTYPES(5); // total number of types
LRR(4), // long range radio message
INVALID(5), // invalid message
NUMTYPES(7); // total number of types
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @berndpfrommer's comment:

why is NUMTYPES initialized to 7? Shouldn't it be 6? Looks like a bug to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Perhaps a typo as I was trying a custom AlarmDecoder format.

LuckyMallari@9c42cd2

@watou watou added this to the 1.9.1 milestone Jan 21, 2017
Corrected NUMTYPES initialized value.
@watou watou modified the milestones: 1.9.1, 1.10.0 Jan 22, 2017
@watou
Copy link
Contributor

watou commented Jan 22, 2017

Thanks @LuckyMallari! Please update the wiki to include this enhancement, noting its first appearance in the 1.10.0 release.

@watou watou merged commit 4ede024 into openhab:master Jan 22, 2017
@LuckyMallari
Copy link
Contributor Author

@watou
Copy link
Contributor

watou commented Jan 24, 2017

Thank you very much, and thanks for the heads-up as well, since I'm in the midst of converting the wiki pages to README.md files so they end up at docs.openhab.org. (See https://github.com/watou/openhab/tree/ded066c197e08d251346827e7e1ac77ef2413a5b/bundles/binding/org.openhab.binding.alarmdecoder) where I've tried to capture your new edits.)

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/added-support-for-alarmdecoder-lrr-protocol/20762/1

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/migrating-my-lua-scripts-to-xtend/38038/2

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/can-alarm-system-sensors-serve-double-duty/39352/7

@openhab-bot
Copy link
Collaborator

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/alarmdecoder-help-ad2pi/42482/17

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants